In recent years, the center of attention as reasonable data service for corporate use is a wide area Ethernet (R) VPN service (wide area Ether) which is an expansion of the Ethernet (R) technique used widely in LAN into a wide area network. Although wide area Ether takes over the advantages of the related Ethernet (R) techniques such as plug and play as easiness to use and low costs, because a MAC address of a user terminal passes in a core network, the number of MAC addresses to be processed by a core switch is enormous. More specifically, the problem is that the amount of MAC address processing (MAC address learning processing, address search processing at the time of frame transfer, etc.) in the core switch bottlenecks or that when the number of MAC addresses accommodated in the core switch is limited, the number of accommodated MAC addresses in the network (the number of accommodated user terminals) is limited.
In order to solve the problem, non-patent Literature 1 proposes the technique called EoE. Although other than the non-patent Literature 1, there exist similar techniques, for example, the MAC in MAC technique discussed in IEEE802.1 and the like, since the problem to be solved which will be described in the following is in common, description will be here made of the non-patent Literature 1.
FIG. 48 shows one example of a wide area Ether network. The wide area Ether network comprises edge switches E5, E6, E7 and E8 which accommodate user terminals T5, T6, T7 and T8, and core switches C3 and C4 which execute only relay operation without accommodating the user terminals.
With the wide area Ether service using the related Ethernet (R) techniques, when ten thousand of user terminals are connected to each edge switch in FIG. 48, for example, the core switch needs to process forty thousands of MAC addresses. On the other hand, with the EoE techniques, a MAC address which is effective only in the network (hereinafter referred to as EoE-MAC address) is set at each edge switch, so that when transferring a frame from a user terminal connected under the switch itself in the network, the frame is encapsulated by the EoE-MAC address and transferred. In FIG. 48, EoE-MAC addresses e5, e6, e7 and e8 are set at the edge switches E5, E6, E7 and E8, respectively.
Next, a frame format will be described. FIG. 49 shows a format of an ordinary Ethernet (R) frame 4300. The Ethernet (R) frame 4300 comprises a destination MAC address 4310, a transmission source MAC address 4320, a Type 4330, a payload 4340 and an FCS (Frame Check Sequence) 4350.
On the other hand, a format of a frame encapsulated by an EoE-MAC address (hereinafter referred to as EoE frame) has an arrangement as shown in FIG. 50. As shown in FIG. 50, an EoE frame 4400 has a format encapsulated with an EoE-MAC address 4410 of a destination edge switch (destination EoE-MAC address), an EoE-MAC address 4420 of its own switch as a transmission source (transmission source EoE-MAC address) and Type 4430 added before an Ethernet (R) frame 4440 and an FCS 4450 added after the Ethernet (R) frame 4440. The Ethernet (R) frame 4440 encapsulated here is equivalent to the Ethernet (R) frame 4300 received from a user terminal with the FCS 4350 deleted.
Format of an Ethernet (R) frame from a user terminal with a VLAN tag added is shown in FIG. 51. An Ethernet (R) frame 4500 with a VLAN tag comprises the destination MAC address 4310, the transmission source MAC address 4320, a VLAN tag 4510, the Type 4330, the payload 4340 and the FCS 4350. In the Ethernet (R) frame 4440 shown in FIG. 50, the Ethernet (R) frame 4500 with a VLAN tag from which the FCS 4350 is deleted is stored in some cases.
The EoE frame 4400 is structured to have a VLAN tag in some cases, and in such a case, the frame comprises the destination EoE-MAC address 4410, the transmission source EoE-MAC address 4420, the VLAN 4510, the Type 4430, the Ethernet (R) frame 4440 and the FCS 4450 as shown in FIG. 52.
Returning to the description of FIG. 48, when the edge switches E5˜E8 receive an Ethernet (R) frame from the user terminals T5˜T8, the switches encapsulate the frame by the EoE-MAC address and transfer the obtained frame to the core network side, resulting in transferring a frame with an EoE-MAC address to the core switches C3 and C4. Therefore, the core switches C3 and C4 should process as many MAC addresses as the number of edge switches in the network. In the example shown in FIG. 48, since the number of edge switches is four, each of the core switches C3 and C4 needs to process four MAC addresses.
While in the above-described example in the existing Ethernet (R) technique, in a case where user terminals on the order of ten thousand are connected to each edge switch, forty thousands of MAC addresses should be processed, with the EoE technique, only four MAC addresses need to be processed. Thus, the EoE techniques have the effect that while the core switch supports standard MAC address transfer, the number of MAC addresses to be processed by a core switch can be reduced to as many MAC addresses as the number of edge switches irrespective of the number of MAC addresses accommodated in the network, which is a technique expandable to a large-scale network.
On the other hand, the Ethernet (R) technique has a possibility that with no countermeasure taken, when a loop structure exists in a network, a frame will continue circulating on the loop and in particular, a broadcast frame circulating will down the network. In order to avoid such a situation, used in many cases are the spanning tree protocol (hereinafter referred to as STP, which technique is defined by IEEE802.1D) for forming a loop-free network by logically excluding the loop even when a physical loop structure exists in the network and a higher version of the same, that is, the rapid spanning tree protocol (hereinafter referred to as RSTP, which technique is defined by IEEE802.1w).
With the STP or RSTP technique used, when any port on a loop structure enters a blocked state (a state where neither transmission nor reception of a main signal frame is executed), a loop-free structure is established. Taking the network shown in FIG. 48 as an example in which there exists a loop structure among the edge switch E7, the core switch C3, the core switch C4 and the edge switch E8, for example, when a port p3 of the core switch C3 enters the blocked state, the structure becomes loop-free.
When such STP and RSTP techniques are used, however, no frame is transferred on a link connected to a blocked port, so that in a case of frame transfer between certain switches, the frame can not be transferred by the shortest path (a path with a minimum number of hops). In the example of FIG. 48, when a frame is transferred from the user terminal T6 to the user terminal T5, since the port p3 of the edge switch E5 is blocked, transfer is impossible from the edge switch E6 to the edge switch E5, so that the frame will be transferred through a path of the edge switch E6->the core switch C4->the edge switch E8->the edge switch E7->the core switch C3->the edge switch E5 to reach the user terminal T5.
As a technique for solving the problem, in non-patent Literature 2 with the use of the technique of Multiple STP (hereinafter referred to as MSTP) capable of management on a plurality of VLANID basis, each edge switch generates an STP/RSTP tree as a transfer path with the switch itself as a route node, and a transfer path of a frame destined for an edge switch as a route node of each STP/RSTP tree is taken as its STP/RSTP tree. Since as a link going active in the STP/RSTP tree (link including no blocked port), a link whose cost of link from a route node is the lowest is selected, the method of the non-patent Literature 2 enables transfer by the shortest path.
Shown in FIG. 53 is an example where the method of the non-patent Literature 2 is used for the above frame transfer from the user terminal T6 to T5 described in FIG. 48. In FIG. 53, frame transfer from the user terminal T6 to T5 is executed by using the STP/RSTP tree with the edge switch E5 as a route node (transfer from the edge switches E7 and E8 to E5 is executed also by using the STP/RSTP tree with the edge switch E5 as a route node). Accordingly, a frame from the user terminal T6 arrives at the user terminal T5 through the edge switch E6 and the edge switch E5. Thus, transfer between the respective nodes can be executed through the shortest path.
In the non-patent Literature 2, the following processing is executed for such transfer. In the transfer between edge switches, with a node ID set at each edge switch stored in a VLAN tag of an Ethernet (R) frame, each edge switch and each core switch execute frame transfer based on the ID.
In FIG. 53, node IDs g11, g12, g13 and g14 are assigned to the edge switches E5, E6, E7 and E8 and in the transfer from the edge switch E6 to the edge switch E5, the VLANID=g11 stored in a VLAN tag is stacked in a frame at the edge switch E6 (the present VLAN tag will be denoted as a forwarding tag) and the edge switch E6 executes frame transfer toward the direction of the edge switch E5 based on the forwarding tag=g11.
In a forwarding table of each switch, an output port for a forwarding tag value is managed and set as an output port is a port number of a route port (a port state at that time is a forwarding state indicative of transfer enabled state) of an STP/RSTP tree with an edge switch having the same node ID as that of the forwarding tag value as a route node. Here, assume that the forwarding tag value (node ID of a destination edge switch) and an identification ID (VLANID) of the STP/RSTP tree are both stored in the VLAN tag and have the same values.
In FIG. 53, the node ID of the edge switch E5 is g11 and an identification ID (VLANID) of the STP/RSTP tree with the edge switch E5 as a route node is also g11, which are respectively stored in the VLAN tag. In the setting of a forwarding table, on a forwarding tag, port information of an STP/RSTP tree identified by the same identifier as a value of the tag will be reflected. In FIG. 53, at each switch, an output port for the forwarding tag g11 reflects port information of the STP/RSTP tree whose VLANID is g1.
Non-patent Literature 1: Ando (Powered Com), “LAN Switch Technology˜Redundancy Method and Latest Technology˜”, Internet Week 2003.
Non-patent Literature 2: Umayabashi et al., “Proposal of Next Generation Ethernet (R) Architecture GOE (Global Optical Ethernet (R))—(2) Highly Efficient Routing and High Speed Protection”, 2002, Institute of Electronics, Information and Communication Engineers of Japan, Society Conference B-7-11.
Description will be made with reference to FIG. 54 whether applying the optimum path transfer technique of the non-patent Literature 2 to the EoE technique of the non-patent Literature 1 described above solves the problem or not that the EoE technique fails to realize optimum path transfer.
Similarly to the non-patent Literature 2, an STP/RSTP tree with each edge switch as a route node is generated by the EoE technique. Because of use of the MSTP technique, an identifier of each STP/RSTP tree will be VLANID. In FIG. 54, the VLANID of the STP/RSTP tree with the edge switch E5 as a route is g11. In addition, in the EoE technique, frame transfer is executed based on an EoE-MAC address as described above.
In FIG. 54, the EoE-MAC address of the edge switch E5 is e5, so that a frame directed to the edge switch E5 is transferred based on the EoE-MAC address e5. Here, when an output port is set by the method of the non-patent Literature 2, each switch is not allowed to determine an output port for an EoE-MAC address because an identifier of an STP/RSTP tree (VLANID) corresponding to the EoE-MAC address is unknown. Thus, simply applying the technique of the non-patent Literature 2 to the EoE technique fails to enable the EoE technique to realize optimum path transfer.